xm: Remove obsolete mechanism using vncviewer -listen

xm: Remove obsolete mechanism using vncviewer -listen

Without this patch, vncviewer processes remain as follows.
This patch fixes it.

> # pgrep -fl vnc
> 4303 vncviewer -log *:stdout:0 -listen 5501
> 5089 vncviewer -log *:stdout:0 -listen 5502
> 5763 vncviewer -log *:stdout:0 -listen 5503

details:
Since 21dd1fdb73d8 there have been (as far as I can see) three
separate mechanisms for achieving a VNC display:
 1. xm spawns vncviewer after getting vnc display info
     from qemu-dm via xenstore  (introduced in 21dd1fdb73d8)
 2. xm spawns vncviewer -listen and qemu-dm connects to it
 3. qemu-dm spawns vncviewer (!)

The latter two are rather strange - No.3 is very strange indeed.
So I decided that rather than try to get No.2 or No.3 on track for
going into qemu upstream, No.2 and No.3 would be dropped.
After discussion on xen-devel the mechanism No.1 was introduced,
above.

No.1 is controlled by the --spawn-vncviewer (and --vncviewer-autopass)
command line options to xm, by analogy with the -c option.

Nos.2 and 3 are controlled by elements of the domain configuration
file - and their code still remains.  So if you turn all of the vnc
options on you can get several vncviewers (although only one of them
will work).

This patch removes the support for the passive connection mode No.2
After all ioemu-remote will never connect to such a vncviewer.
The options to engage this functionality were already removed from
the example config files by Keir in 18241:bf4ef45e6a38.

Signed-off-by: Isaku Yamahata <yamahata@valinux.co.jp>